1. Field of the Invention
This invention relates generally to the field of utility software, and more particularly relates within that field to improved product release software which, at least, prepares customer-software to be automatically customizable by the customer at runtime.
2. Description of Prior Art
Before discussing prior art to the present invention, to place it in context refer to FIG. 1. There is depicted a software “field” showing three basic divisions of software: (1) Firmware or BIOS (Basic Input/Output System); (2) Operating System software; and (3) Applications software. The relationship of these various software categories to each other is generally suggested by their respective juxtapositions in the diagram. The firmware (BIOS) software is needed to get a computer system “booted-up” or turned on. The operating system runs on top of the BIOS and is needed to bring that computer system to “life”, to enable it to run or operate—kind of the lifeblood of the computer system. The application software runs on the operating system software, and directs that computer system in a particular task of interest. A detailed discussion of each of the entries on the software field is not undertaken herein as each entry is self-explanatory. This software field is not complete and other software entries could have been made, known by names such as: daemons, processes, threads, API, sockets, algorithms, data structures, etc. Each of these other software names has special meaning in the software arts. Software depicted in FIG. 1, this other software, and yet other software not mentioned can all have a role to play in producing and controlling an operational computer by functionally-interconnecting with each other and with the computer system's firmware and hardware in a concerted effort to manage or control overall computer system operation in a manner to provide the result desired by the computer system human user. The present invention relates to a category of applications software known as “utilities” which is shown in FIG. 1, and relates to a particular type of utility software known as product release software—software which aids in readying or producing other software for consumer or customer usage on or within the customer's computer system.
Although the categories of application software are shown in the field as being isolated from each other for purposes of clarity of presentation, that is not necessarily the case. For example, the product release software within the utilities category is shown separated from the other categories of applications software, but it relates closely to the Tools category and could have been shown within or connected to that category under the more generic heading of a tool used to manage memory or storage such as disk arrays.
As is understood by those familiar with the computer arts, a human language such as English is used by programmers or software developers to create “files” and put commands and code in those files. These source code files are compiled by a compiler program into binary language understandable by the computer. There may be many source code files and each needs to be compiled. The compiled source code is called an object file. In order to construct a program one needs to combine or link all of the object files into a single file called the executable or binary file by way of a linker program. Not all of the object files contained in the executable or binary file are intended to be executed, although such non-executable files can remain within the binary file. Alternatively, some of the object files which were not intended to be executed can be combined by the linker into a different file such as a library file.
With any discussion focused primarily on computer programming and software, one could lose sight of ultimate computer system operation: regardless of size or complexity of the computer system or computer system network, including multiple layers of software, in every system electrons ultimately flow over conductive paths and through electrical nodes in a manner such that for every digital subsystem the nodes are either at a high voltage (high) or low voltage (low) at any given clock cycle (snapshot in time), and there could be multiple clocks. It is the controlling of each of these nodes or circuit-component-junctions, (e.g.: junctions between individual resistors and capacitors, junctions between individual transistors' emitters, bases or collectors and other active or passive circuitry, etc.), which may number possibly in the billions or even trillions per computer system when considering the huge number of integrated circuits that can be employed, to be either high or low at any specific point in time, and the controlling of how each one of these nodes changes from high to low and vice versa, which is the job of the various pieces of software on the computer system working in concert with each other. This concerted effort produces the desired result for the human computer user.
The prior art to the present invention includes utility software apparatus and methodology which human software developers use at “design-time”—at the time that source code is being written—to customize application software. (Software developers typically consider the development cycle to be divided into various “times” such as design time when the source code is written, code implementation time when at least compiling and linking are performed, kit time when the customer's kit is prepared, ship time when the kit and related software are shipped, and run time when the kit and related software are run normally at the customer's site.) This prior art utility software becomes an integral part of the application source code software and of its compiled binary intended for delivery to such customer-user. As an example of an application of this prior art utility software, consider the scenario where a computer company employs a team of software developers (“team” is intended to mean more than one person and can include people from the same department or from various departments within a single company or multiple companies) to develop graphical user interface (GUI) software to run on its own computer systems which it markets. Certain OEM (original equipment manufacturer) customers purchase those systems from the computer company but prefer to incorporate their own GUI nomenclature, (i.e. logo, splash-screen, etc.), so that when an OEM'S end user customer runs a system purchased from that OEM the GUI displays only that OEM's nomenclature and not any of the original computer company's nomenclature.
Prior art software employed in the GUI context includes usage of certain resource file(s) within the source code application software that define all visual elements or resources. (On a computer screen, for example, the “dialog box” is a resource, the “title bar” contained within the dialog box is a resource, etc.) In this prior art approach, resources can be changed, but only directly by developers at “design time” when the developers are constructing the software. Resources will be changed, for example, when a different visual look-and-feel is required for a different customer user. (In a specific example, a computer system and software provider would normally have its own logo or “splash-screen” as a visual resource that ships with the software, but an OEM customer purchasing such software and system would normally want to substitute its own OEM logo or splash-screen.) Because the prior art utility product release software was integrated into the source code of the application software to be shipped to the customer, this entailed rewriting vast portions of the entire application software source code, not only the resource files, each time a new customer wanted its own new computer screen image or each time an old customer wanted an update or revision to its old computer screen image. For example, in the prior art, the team of developers had to perform five separate steps to accomplish customization, namely: (1) write source code and imbed into this code the customization requested by the OEM/user/customer; (2) compile the source code to obtain binary files (as discussed); (3) link the files using a linker program (as discussed); (4) repeat steps 1, 2, 3 for every module needed; and (5) prepare the customer's kit installing the customized software onto a CD (compact disk). If any changes were required, all steps had to be performed, starting with rewriting the source code which is the most expensive step and a major challenge.
Other prior art challenges of a similar nature appear in the “Internationalization” arena. There are requirements for software (computer code) written in one human language, say English using the “Visual C++” computer language, to be translated into many foreign languages and/or foreign alphabets, such as, for example, Farci, Hebrew, Arabic, Greek, Russian, Japanese, Chinese and others, at least at the GUI level. In other words, English-language messages and icons on a computer screen may not normally be understood and therefore not normally be useful in a particular foreign country such as Turkey where Farci is spoken and it would therefore be very useful for a computer user/customer in Turkey to have such GUI icons and other GUI resources presented in Farci. In the prior art, these foreign-language GUI resources can be changed but, again, only directly by the developers in the source code at design time which presents the challenges and problems noted above.
Moreover, if a software bug was somehow introduced into the software development process at design time from a particular customer's particular specifications for its particular computer screen image (whether such specifications are resource-related or language-related or otherwise) but not detected until later, perhaps not until that software was shipped and run at that customer's site, then, in the meantime, such a bug could also infect other related software being customized for other customers. Resource files, for example, containing software reflecting customer specifications are intertwined with the source code and are not separately extractable and repairable. Thus, the only fix available would then be to rewrite entire portions of the source code for each and every infected customer to undo the bug. This prior art procedure for preparing application software for customer usage and for fixing bugs in such software was and is a large problem for software developers. As noted above, this prior art problem is particularly acute when there are a large number of different customer-users who each need to get their application software fixed because a particular bug is common to all customers' application software. In such a case, each users' software has to be individually rewritten which is a major headache.
In short, prior art disadvantages and problems arising from the intimate relationship between application software and these resources are derived from the following complexities: (1) when resources are changed, the complete application software has to be rebuilt and relinked; (2) resource changes may introduce bugs to the overall application software; and, (3) there is a considerable management effort required if several different resource files and application binaries with different built-in resources have to be maintained. What was badly needed was a solution to avoid this waste of effort, time and money caused by the necessity of rewriting source code and handling the complete application when bugs or like problems arise. The present invention provides such a welcome solution, to be described hereinbelow.